Pushed a fix, using true instead of : since it's a little more clear what's going on.

Hmm, OK so this is a bit more complicated actually. Inside the container, selinuxfs isn't mounted, so getenforce will return "Disabled". That said, testing this I don't hit #292, which was the original motivation for that chcon, so I can't verify that it breaks things. But I suspect it would. So doing chcon || echo ... as you had originally is better for now, though we should probably get to the bottom of why MCS labels are being created in the first place on @dustymabe's computer.

are you running unprivileged? note that robert also was able to reproduce: #294 (review)

Yes - I previously hit a "permission denied" during cosa run unprivileged after cosa build, but with the fix in #294 applied, cosa run unprivileged succeeded. I should have checked the context of the file ${img_qemu} at the time to be sure that it was MCS labels being applied that caused the unprivileged command to fail (I'll double check the audit log on my laptop later, where I tested that, as the AVC should still be there).

Checking out latest master at d48e618, mounting the scripts, and running cosa init unprivileged, it looks like /usr/bin/coreos-assember has MCS labels applied. I wonder if you hit this @jlebon? I've recently been running with export COREOS_ASSEMBLER_PRIVILEGED=true, so I did not hit this before.

$ cosa init https://github.com/coreos/fedora-coreos-config
COREOS_ASSEMBLER_GIT=/srv/coreos-assembler/
+ sudo podman run --rm -ti -v /srv/srv-coreos:/srv/ --userns=host --device /dev/kvm --name cosa -v /srv/coreos-assembler//src/:/usr/lib/coreos-assembler/:ro quay.io/coreos-assembler/coreos-assembler:latest init https://github.com/coreos/fedora-coreos-config
[dumb-init] /usr/bin/coreos-assembler: Permission denied
+ rc=2
+ set +x

$ sudo ausearch -m avc --start 10:44:00
----
time->Wed Mar  6 10:45:44 2019
type=AVC msg=audit(1551887144.182:533): avc:  denied  { execute } for  pid=6242 comm="dumb-init" name="coreos-assembler" dev="dm-0" ino=528647 scontext=system_u:system_r:container_t:s0:c249,c689 tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0

$ sudo podman images
REPOSITORY                                  TAG      IMAGE ID       CREATED        SIZE
quay.io/coreos-assembler/coreos-assembler   latest   4cb1ef429eeb   24 hours ago   3.58 GB

(running on F29)

Ok, switched back to what it was originally.

OK, reproduced this now: fixed in #394, which also drops the chcon call.

Superceded by #394